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Abstract 

This paper describes Picat’s planner, its implementation, and planning models for several do¬ 
mains used in International Planning Competition (IPC) 2014. Picat’s planner is implemented 
by use of tabling. During search, every state encountered is tabled, and tabled states are used 
to effectively perform resource-bounded search. In Picat, structured data can be used to avoid 
enumerating all possible permutations of objects, and term sharing is used to avoid duplication 
of common state data. This paper presents several modeling techniques through the example 
models, ranging from designing state representations to facilitate data sharing and symmetry 
breaking, encoding actions with operations for efficient precondition checking and state updat¬ 
ing, to incorporating domain knowledge and heuristics. Broadly, this paper demonstrates the 
effectiveness of tabled logic programming for planning, and argues the importance of modeling 
despite recent significant progress in domain-independent PDDL planners. 


1 Introduction 


Planning and logic programming are two close areas of research. PLANNER (Hewitt 


1969), which was designed as a language for proving theorems and manipulating models 


in a roboh is perceived as the first logic programming language. Planning has been 


an important problem domain for Prolog (Kowalski 1979; Warren 1974). Despite the 


amenability of Prolog to planning, Prolog is no longer a competitive tool for planning. 


Tabling (Michie 1968; Tamaki and Sato 1986 Warren 1992) is a technique used in logic 
and functional programming systems, which caches the results of certain calculations in 
memory and reuses them in subsequent calculations through a quick table lookup. Like 
state marking used in search algorithms, tabling can prevent the same state from being 
expanded more than once during search. Tabling has been found useful in many search 
problems, including theorem proving ( Nielson et al. 2004} Pientka 2003), program analysis 
(Dawson et al. 1996) and model checking (Ramakrishna et al. 1997). Recently, tabled 


logic programming has been successfully employed to solve specific planning problems 


(Bartak and Zhou 2014 Zhou and Dovier 2013 Zhou 2014), and has been shown to be 
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significantly faster than the state-of-the-art ASP (Answer Set Programming) planners 
on some problems (Zhou and Dovier 2013 Zhou 2Q14| ). 

This paper describes Picat’s planner and its implementation. This paper also presents 
planning models in Picat for several domains used in International Planning Competition 
2014 (IPC’14) (Chrpa et ah 2014), and demonstrates broader applicability of tabled logic 
programming to planning. Picat is a logic-based multi-paradigm language that provides 
logic variables, pattern matching, nondeterminism through backtracking, loops, func¬ 
tions, constraints, and tabling as its core modeling and solving features. As a modeling 
language for planning, Picat differs from PDDL (Plan Domain Description Language) 
( McDermott 199^ and ASP ( Brewka et al. 201 1[ Gebser et al. 20 [Lifschitz 2002| ) 
in several aspects: (1) Picat allows use of structures to represent states; (2) Picat sup¬ 
ports explicit commitment and nondeterministic actions, which enables users to have 
better control over action applications; (3) Picat provides facilities for describing domain 
knowledge and heuristics for pruning search space. 

As a solving system, Picat’s planner implements several techniques for better perfor¬ 
mance. First, it tables every state encountered during search and avoids repeating the 


exploration of the same state. Second, it adopts the hash-consing technique (Zhou and 


Have 2012) to share common state data and to speed up the equality testing of states. 


Third, it utilizes tabled states to effectively perform resource-hounded search. For optimal 
planning, Picat offers built-ins to perform iterative search, but unlike IDA* (Korf 1985), 
Picat also reuses results tabled in early iterations (Zhou 2014). 

This paper shows that the above-mentioned features of Picat make Picat a more ap¬ 
propriate language than PDDL for modeling and solving planning problems. To that 
end, this paper presents examples in Picat for several domains used in IPC’14. These 
examples illustrate several modeling techniques on how to design state representations 
to facilitate data sharing and symmetry breaking, on how to translate PDDL operators 
into Picat actions, and on how to incorporate domain knowledge and heuristics to reduce 
search spaces. This paper also gives the experimental results of the presented models and 
several other models encoded in the same way. The experimental results demonstrate the 
effectiveness of tabling and the importance of modeling. 


2 A Brief Overview of Picat 

Picat is a dynamically-typed language. The basic types are taken from Prolog, except 
for arrays and maps. An array takes the form {ti,.. The index of the first array 

element is 1, and the index notation X [I] can be used to access array elements. Picat also 
borrows the basic logical operators from Prolog, including conjunction negation 

(not A), disjunction and if-then-else {C->A; B). 

Picat allows function calls in arguments. For this reason, it requires structures to be 
preceded with a dollar symbol $ in order for them to be treated as data, unless the 
structure is special, or it occurs in a head pattern. 

For each type, Picat provides a set of built-in functions and predicates. Many built- 
in predicates are taken from Prolog, including member/2, nth/3, and select/3. The 
function insert_ordered(List,Term) inserts Term into the ordered list List such that 
the resulting list remains ordered. 

In Picat, predicates and functions are defined with pattern-matching rules. Picat has 
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two types of rules: the non-backtrackable rule Head^Cond => Body^ and the backtrack¬ 
able rule Head^Cond ?=> Body. In a predicate definition, the Head takes the form 
p(ti,..., tn), where p is a predicate name, and n is the arity. The condition Cond^ which 
is an optional goal, specifies a condition under which the rule is applicable. For a call C, if 
C matches Head and Cond succeeds, then the rule is said to be applicable to C. When ap¬ 
plying a rule to call C, Picat rewrites C into Body. If the used rule is non-backtrackable, 
then the rewriting is a commitment, and the program can never backtrack to C. How¬ 
ever, if the used rule is backtrackable, then the program will backtrack to C once Body 
fails, meaning that Body will be rewritten back to C, and the next applicable rule will 
be tried on C. In a function definition, the Head takes the form /(ti ,... pn) = Term 
where / is a function name and Term is a result to be returned. All of the rules in a 
function definition must be non-backtrackable. 

A pattern can contain as-patterns of the form V^Pattern^ where H is a new variable 
in the head, and Pattern is a non-variable term. The as-pattern V^Pattern is the same 
as Pattern in pattern matching, but after pattern matching succeeds, V is made to 
reference the term that matched Pattern. 

Picat supports loops and list comprehensions. For example, the loop 

foreach(E in L) Goal end 

is true if Goal is true for each E in L. Picat adopts the following simple scoping rule: 
variables that occur only in a loop, but do not occur before the loop in the outer scope, are 
local to each iteration of the loop. Loops are compiled into tail-recursive predicates, and 
list comprehensions are compiled into tail-recursive predicates through foreach loops. 

Picat supports tabling for dynamic programming solutions. Other features of Picat 
include assignments, list comprehensions, global maps for storing permanent data, higher- 
order functions, action rules for defining event-driven actors, and modules for modeling 
and solving constraint satisfaction problems with CP, SAT, and MIP. 


3 Tabling in Picat 


Both predicates and functions can be tabled. In order to have all calls and answers of a 
predicate or function tabled, users just need to add the keyword table before the first 
rule. For a predicate definition, the keyword table can be followed by a tuple of table 
modes, including + (input), - (output), min, max, and nt (not tabled). For a predicate 
with a table mode declaration that contains min or max, Picat tables one optimal answer 
for each tuple of the input arguments. The last mode can be nt, which indicates that the 
corresponding argument will not be tabled. 


Linear tabling (Zhou et al. 2008) is used in Picat, and table modes are taken from 


(Guo and Gupta 2008), except for the nt mode, which was initially proposed by (Zhou 


et al. 2010). Ground structured terms are hash-consed (Zhou and Have 2012) so that 


common ground terms are tabled only once. For example, for the three lists [1,2,3], 
[2,3], and [3], the shared sub-lists [2,3] and [3] are reused from [1,2,3]. 

Mode-directed tabling has been succes sfully used to solve specific planning p roblems 
such as Sokoban (Zhou and Dovier 2013), and the Petrobras planning problem (Bartak 
and Zhou 2014). A planning problem is modeled as a path-finding problem over an 
implicitly specified graph. The following gives the framework used in all these solutions. 
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Fig. 1. A DAG. 


table (+,-,miii) 

path(S,Path,Cost), final(S) => Path = [],Cost = 0. 
path(S,Path,Cost) => 

action(S,SI,Action,ActionCost), 
path(Sl,Pathl,Costl), 

Path = [Action IPathl], 

Cost = Costl+ActionCost. 


The call path(S,Path,Cost) binds Path to an optimal path from S to a final state. The 
predicate final(S) succeeds if S is a final state, and the predicate action encodes the 
set of actions in the problem. 

Consider using the path/3 predicate to find a shortest path from node a to node d in 
the DAG shown in FigureThe final state is d. The call path(a,Path,Cost) initiates 
the search from node a. In order to resolve the call, Picat applies the transition a^b to 
node a, and generates a new call to path for finding a shortest path from b to d. After 
the answer b—^c^d is found for the call, Picat tables the answer a^b^c^d, which has 
cost 8, for the inital call. After that, Picat backtracks, trying the alternative transition 
a^c to node a. After the shortest path c^d is found, Picat finds another path a^c^d, 
which has cost 5, for the initial call. Since this path is shorter than the tabled path, 
Picat replaces the tabled path with this new path. Since the graph has no cycles, Picat 
returns the new path as the final answer. In general, calls need to be re-evaluated until 
fixed points are reached if there are looping calls (Zhou et al. 2008). 

When applied to the single-source shortest path problem, linear tabling is similar to 
Dijkstra’s algorithm, except that linear tabling tables shortest paths from the encountered 
states to the goal state rather than shortest paths to the encountered states from the 
initial state. 

The above framework performs depth-unbounded search. For many planning problems, 
branch & bound and IDA* (Korf 1985) are useful for finding optimal solutions. The 
planner module of Picat provides built-ins for planning with different types of search. 


4 The planner Module of Picat 

The planner module is based on tabling but it abstracts away tabling from users. For a 
planning problem, users only need to define the predicates final/1 and action/4, and 
call one of the search predicates in the module on an initial state in order to find a plan 
or an optimal plan. 

• finales'): This predicate succeeds if S is a final state. 

• diCtloiiiSyNextSy Actiony ACost): This predicate encodes the state transition di¬ 
agram of a planning problem. The state S can be transformed to NextS by per- 
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forming Action. The cost of Action is ACost^ which must be non-negative. If the 
plan’s length is the only interest, then ACost = 1. 


These two predicates are called by the planner. The action predicate specifies the pre¬ 
condition, effect, and cost of each of the actions. This predicate is normally defined with 
nondeterministic pattern-matching rules. As in Prolog, the planner tries actions in the 
order they are specified. When a non-backtrackable rule is applied to a call, the remaining 
rules will be discarded for the call. 

The following predicates constitute the core of the planner module. 


best_plan_unbounded(S',Limit,P/an,P/an(7ost): This predicate finds an opti¬ 
mal plan by performing depth-unbounded search. This predicate is implemented 
based on the path-finding framework shown above. The argument Limit is not uti¬ 
lized to limit the depth of search. It is compared with PlanCost after an optimal 
plan has been found. During depth-unbounded search, once a state has failed, it 
will not be explored again. 

plan(S, Limit , Plan , PlanCost) : This predicate searches for a plan by performing 
resource-bounded search, in which a state is expanded only if it is new and its 
resource limit is non-negative, or if the state has previously failed but the current 
occurrence has a higher resource limit than before. This predicate is defined as 
a tabled predicate that tables the Limit argument but does not use it in variant 
checking (Zhou 2014). The implementation of this predicate is described in the next 
subsection. 

hest,Limit,Plan,PlanCost): This predicate finds an optimal plan by 
performing resource-bounded iterative-deepening search. It calls the plan/4 predi¬ 
cate to find a plan, using 0 as the initial cost limit and gradually relaxing the cost 
limit until a plan is found. Unlike IDA*, which starts a new round from scratch, 
Picat also reuses the states that were tabled in the previous rounds, 
be St _pl an_bb( S', Limit, P/an, Cost) This predicate finds an optimal plan using 
branch & bound. First, it calls plan/4 to find a plan. Then, it tries to find a better 
plan by imposing a stricter limit. This step is repeated until no better plan can be 
found. It returns the last plan that was found. 

current_resource(): This function returns the resource limit argument of the 
latest call to plan/4. In order to retrieve the argument, the implementation has to 
traverse the call-stack until it reaches a call to plan/4. This function can be used 
to check against a heuristic value. If the heuristic estimate of the cost to travel 
from the current state to a final state is greater than the resource limit, then the 
current state should fail. 


5 The Implementation of Resource-Bounded Search 

Figure [^sketches Picat’s implementation of the predicate plan/4. The following array is 
passed from a state to the next state as an nt argument: 

{Limit,IPlan,IPlanCost} 

In order to perform resource-bounded search, Picat treats the second argument of the 
predicate plan_bounded_aux differently from other nt arguments. Picat stores the Limit 
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plan(S,Limit,Plan,PlanCost) => 

IPlan = {Limit,[], 0}, 

catch(plan_bounded_aux(S,IPlan), (Plan,PlanCost), true), 
table (+,nt) 

plan_bounded_aux(S,{Limit,IPlan,IPlanCost}), 
final(S) 

=> 

throw((IPlan.reverse(), IPlanCost)). 
plan_bounded_aux(S,{Limit,IPlan,IPlanCost}) => 
action(S,NextS,Action,ACost), 

Limit1 = Limit-ACost, 

Limit1 >= 0, 

Inheritedl = {Limitl, 

[Action IIPlan], 

IPlanCost+ACost}, 

plan_bounded_aux(NextS,Inheritedl). 

Fig. 2. The implementation of plan/4. 



Fig. 3. Resource-bounded search. 


argument of each failed call to plan_bounded_aux, and uses this information to decide 
whether the same state should fail when it recurs. 

The first rule of plan_bounded_aux throws the inherited plan and its cost as an ex¬ 
ception if final(S) succeeds. The exception will be caught by the catch call in the rule 
body of plan/4. 

The second rule of plan_bounded_aux calls action/4 to select an action, which pro¬ 
duces a new state, NextS. Then, the rule computes the new resource limit, Limitl, by 
subtracting the cost of the selected action from Limit. If Limitl >= 0 succeeds, then 
the rule continues with the tabled search by recursively calling plan_bounded_aux on 
the new state NextS. Otherwise, if Limitl >= 0 fails, then Picat backtracks to select an 
alternative action. 

The idea of resource-bounded search is to utilize tabled states and their resource limits 
to effectively decide when a state should be expanded and when a state should fail. 
Let denote a state with an associated resource limit, R, as depicted in Figure 
If R is negative, then immediately fails. If R is non-negative and S has never been 
encountered before, then S is expanded by using a selected action. Otherwise, if the same 
state S has failed before and R' was the resource limit when it failed, then is only 
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expanded if R > R', i.e., if the current resource limit is larger than the resource limit 
was at the time of failure. 


6 Modeling Examples 

This section describes the Picat models for four of the problem domains used in the 
sequential optimal track of IPC’14: Transport, Tetris, Floortile, and Parking. Each of the 
following models will show the state representation, the encoding of the actions, the search 
predicate that is used (best_plan or best_plan_unbounded), and the domain knowledge 
and heuristics that are employed. In these models, states are typically represented by lists, 
and preconditions and state updates are handled by standard list operations. Sometimes, 
arrays are used when no list suffixes can be shared. The Picat encodings of actions are 
mostly straightforward translations from the PDDL encodings. These models do not 
use sophisticated domain knowledge or heuristics that would hurt the readability or 
compromise the optimality of answers. These four domains, as well as five other domains, 
are described in Appendix A. 


6.1 Example-1: Transport 

This problem is a variant of the popular logistics domain in planning. Given a weighted 
directed graph, a set of trucks each of which has a capacity for the number of packages it 
can carry, and a set of packages each of which has an initial location and a destination, 
the objective of the problem is to find an optimal plan to transport the packages from 
their initial locations to their destinations. This problem is more challenging than the 
Nomystery problem that was used in IPC’ll, because of the existence of multiple trucks, 
and because an optimal plan normally requires trucks to cooperate. This problem degen¬ 
erates into the shortest path problem if there is only one truck and only one package. 
The PDDL and Picat encodings of the problem are given in Appendix B. 


Basic Encoding 

A state is represented by an array of the form {Trucks,Packages}, where Trucks is an 
ordered list of trucks, and Packages is an ordered list of waiting packages. A package in 
Packages is a pair of the form (Loc,Dest) where Loc is the source location and Best is 
the destination of the package. A truck in Trucks is a list of the form [Loc,Bests, Cap], 
where Loc is the current location of the truck. Bests is an ordered list of destinations of 
the loaded packages on the truck, and Cap is the capacity of the truck. At any time, the 
number of loaded packages must not exceed the capacity. 

Note that keeping Cap as the last element of the list facilitates sharing, since the suffix 
[Cap], which is common to all the trucks that have the same capacity, is tabled only once. 
Also note that the names of the trucks and the names of packages are not included in the 
representation. Two packages in the waiting list that have the same source and the same 
destination are indistinguishable, and as are two packages loaded on the same truck that 
have the same destination. This representation breaks symmetries. Two configurations 
that only differ by a truck’s name or a package’s name are treated as the same state. 

A state is final if all of the packages have been transported. 
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final ({Trucks,[] }) => 

foreachC[_LocjDestsI_] in Trucks) 

Bests == [] 

end. 

The PDDL rules for the actions are straightforwardly translated into Picat as follows. 

action({Trucks,Packages},NextState,Action,ACost) ?=> 

Action = $load(Loc), ACost = 1, 
select( [Loc,Bests,Cap],Trucks,TrucksR), 
length(Bests) < Cap, 

select((Loc,Best),Packages,PackagesR), 

NewBests = insert_ordered(Bests,Best), 

NewTrucks = insert_ordered(TrucksR,[Loc,NewBests,Cap]), 

NextState = {NewTrucks,PackagesR}, 
action({Trucks,Packages},NextState,Action,ACost) ?=> 

Action = $unload(Loc), ACost = 1, 
select( [Loc,Bests,Cap],Trucks,TrucksR), 
select(Best,Bests,BestsR), 

NewTrucks = insert_ordered(TrucksR,[Loc,BestsR,Cap]), 

NewPackages = insert_ordered(Packages,(Loc,Best)), 

NextState = {NewTrucks,NewPackages}. 
action({Trucks,Packages},NextState,Action,ACost) => 

Action = $move(Loc,NextLoc), 
select([Loc|Tail],Trucks,TrucksR), 
road(Loc,NextLoc,ACost), 

NewTrucks = insert_ordered(TrucksR,[NextLoc|Tail]), 

NextState = {NewTrucks,Packages}. 

For the load action, the rule nondeterministically selects a truck that still has room for 
another package, and nondeterministically selects a package that has the same location as 
the truck. After loading the package to the truck, the rule inserts the package’s destination 
into the list of loaded packages of the truck. Note that the rule is nondeterministic. Even 
if a truck passes by a location that has a waiting package, the truck may not pick it. 
If this rule is made deterministic, then the optimality of plans is no longer guaranteed, 
unless there is only one truck and the truck’s capacity is infinite. 


Domain Knowledge and Heuristies 

Domain knowledge can be used to reduce the nondeterminism and avoid unnecessary 
applications of actions. In the complete Picat encoding given in Appendix B, the predi¬ 
cate action begins with a rule that deterministically unloads a package if the package’s 
destination is the same as the truck’s location. 

Resource-bounded search is used to find an optimal plan. After each new state is 
generated, the following condition is checked to ensure that the current path is viable. 

current_resource0 - ACost >= estimated_cost(NewState). 

Let Pi, ..., Pn be the remaining packages, and Ci be the minimum cost of moving 
package Pi to its destination by using any truck. The moving cost of a state can be safely 
estimated as max({(7i,..., (7^}). The estimated total cost is the estimated moving cost 
plus the loading and unloading costs of all of the remaining packages. This heuristic is 
admissible. 




Planning as Tabled Logic Programming 


9 


6,2 Example-2: Tetris 

The problem is a simplified version of the well-known Tetris. There are three kinds of 
pieces: 1-cell boxes^ 2-cell rectangles^ and 3-cell L-shaped pieces. Initially, all the pieces 
are distributed on a grid board. The pieces can freely move on the board to any cells as 
long as the cells are not occupied by other pieces. There is a region on the board that 
is designated as the target region. The goal of the game is to move all the pieces to the 
target region. In the IPC setting, rectangles can rotate but L-shaped pieces cannot. 


Basic Encoding 

Pieces can be represented as follows: A square is represented by the cell it occupies; a 
rectangle by a term of the form rect(Cl,C2) where Cl and C2 are cell locations; and an 
L-shaped piece by a term of the form ell(Cl,C2,C3) . In the IPC setting, the ordering 
of the cells that are occupied by a piece is important. So rect (Cl ,C2) and rect (C2 ,C1) 
represent two different rectangle pieces. A state is represented by an array of the form 
{Squares,RectSjLs}, where each argument gives a sorted list of a single kind of pieces. 

The PDDL rules for actions can be translated into Picat in a straightforward manner. 
For example, the following rule selects a rectangle piece to move. 

actioii(State@{SquaresjRects,Ls}jNewState,Action,ACost) ?=> 

Action = $move(RectjNewRect), ACost = 1, 
select(Rect,RectsjRectsR), 

Rect = $rect(Cl,C2), 
connected(C2,C3), 

not_occupied(C3,State) , 7o7o C3 is free 

NewRect = $rect(C2,C3), 

NewState = {Squares,insert_ordered(Rects,NewRect),Ls}. 

The predicate not_occupied(C3, State) is true if C3 is not occupied by any of the pieces 
in State. 


Heuristics 

Resource-bounded search is used to find an optimal plan for this problem. The goal of 
the problem is to move all the pieces to the target region. For each piece, assume that it’s 
the only piece on the board, disregarding all other pieces. The estimated cost of moving 
the piece to the target region is its shortest distance to the nearest cell in the target 
region times the cost of each move. The estimated cost of transforming a state into a 
final state is the sum of the estimated costs of all the pieces. This heuristic function is 
admissible and easy to compute, but very conservative because a cell in the target region 
can serve as a target for multiple pieces. 

6,3 Example-3: Floortile 

A set of robots use two different colors (black and white) to paint patterns in floor tiles. 
The robots can move around the floor tiles in four directions (up, down, left and right). 
Robots paint with one color at a time, but can change their spray guns to the other color. 
However, robots can only paint the tile that is in front (up) and behind (down) them, 
and once a tile has been painted no robot can stand on it. 
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Basic Encoding 

A state is represented by a list of the form [Robots ,WTiles ,BTiles], where Robots 
is an ordered list of robots and WTitles (BTiles) is an ordered list of locations of the 
painted white (black) tiles. A robot in Robots is a pair (Color,Loc) where Color is the 
color of the paint that the robot is holding and Loc is the robot’s location. 

A state is final if all the tiles that are required to be painted are all painted. 

final({_,WTiles,BTiles}) => 

paiiited_w_tiles_iii_goal (WTiles) , 
paiiited_b_tiles_iii_goal (BTiles) . 

The actions are encoded according to the state representation. For example, once a 
tile is painted, the tile’s location is added into WTiles or BTiles depending on the color 
of the paint; once a robot (Color,Loc) moves from Loc to Loci, the pair is changed to 
(Color,Loci). The current graph is determined by the initial graph, the set of painted 
tiles, and the set of robots. A robot can move from its current location Loc to a new 
location NextLoc if NextLoc is connected to Loc in the graph, NextLoc is not painted, 
and NextLoc is not occupied by another robot. 


Macro Actions and Domain Knowledge 

The color-changing action, if needed, can be forced to take place right before a painting 
action. This macro action helps reduce the search space. 

For IPC’14, the used instances were generated in the fashion that robots should only 
paint tiles in front of them. This special condition can be exploited to reduce the non¬ 
determinism of the painting rules: if a robot is at location Loc, trying to paint the up 
location ULoc, and the up location of ULoc has already been painted, then ULoc can be 
painted deterministically; similarly, if a robot is at location Loc, trying to paint the down 
location DLoc, and the down location of DLoc has already been painted, then DLoc can 
be painted deterministically. 

Depth-unbounded search is used for this problem. During depth-unbounded search, 
dead ends are tabled and are not re-explored when they are encountered again. For this 
problem, a state becomes a dead end if there is an unpainted tile that is not reachable 
by any robot. No extra code is needed to detect dead ends. Because depth-unbounded 
search is used, no heuristics are needed. 


6,4 Example-4: Parking 

This domain involves parking cars on a street with N curb locations, and where cars 
can be double-parked but not triple-parked. The goal is to find a plan to move from 
one configuration of parked cars to another configuration, by driving cars from one curb 
location to another. For each curb location, there are two parking spots: the curb side 
and the road side. For a car to move from a spot at a curb into a spot at a different curb, 
the destination spot must be clear; and if the spot is on the curb side, then the road-side 
spot must also be clear. In some ways, this problem is similar to the Blocks World and 
the Tower of Hanoi. 
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Basic Encoding 

A configuration is represented by an array of curbs {5i, ^ 2 , • • •, where each Bi is a 
list of up to two cars. When a curb has two cars [Ci ,C 2 ^, it is assumed that Ci is the 
road-side car and C 2 is the curb-side car. This representation allows the road-side car Ci 
to be removed without touching the curb-side car (72- 

A state is represented by a pair of the form (CurrConfig,GoalConfig), where a 
CurrConfig is the current configuration, and GoalConfig is the goal configuration. As 
shown below, the inclusion of the goal configuration in the state representation facilitates 
the encoding of domain knowledge. 

A state is final if the current configuration is the same as the goal configuration. 

final((ConfigjConfig)) => true. 

All possible moves are specified with one rule as follows: 

actionC(ConfigjGConfig),NextS,Action,ACost) => 

Action = $move(I,J), ACost = 1, 

nth(I,Config,ICars),ICars = [ClearCar|NewICars], 

nth(J,Config,JCars), J !== I, JCars != 

N = length(Config), 

NewConfig = new_array(N), 
foreach (K in 1..N) 

(K == I -> NewConfig[K] = NewICars 

;K == J -> NewConfig[K] = [ClearCar|JCars] 

; NewConfig[K] = Config[K]) 

end, 

NextS = (NextConfig,GConfig). 

The built-in predicate nth(I, Array ,Arg) is true if the I-th argument of Array is Arg. 
When I is a variable, this predicate nondeterministically searches for an argument that 
unifies with Arg. The rule finds a non-empty curb I and a different curb J that has less 
than two cars, and moves the clear car, ClearCar, from curb I to curb J. 


Domain Knowledge and Heuristics 


Two knowledge rules can be incorporated into the basic encoding in order to speed up 
the search. First, when a car is moved into a spot that is its final spot in the goal 
configuration, such a move should be made deterministically. Note that if a car is moved 
to a road-side final spot then the curb-side spot must be occupied by a correct car. 
Second, a car that has been placed in its final spot should not be moved away. This kind 


of domain knowledge has been used in solving the Tower of Hanoi (Alford et al. 2009) 


and the Blocks World (Bacchus and Kabanza 2000) 


Resource-bounded search is used to find an optimal plan. The cost of transforming a 
state to a final state can be simply estimated as the number of incorrectly-positioned 
cars. This estimation is admissible, since at least one action is needed to move each 
incorrectly-positioned car. The following improved heuristic function, which takes special 
curb configurations into account, is used by the model: For each curb, if the curb has 
two cars [A,B] in the current state, but is required to have [B,A] in the final state, then 
its cost is 4; if the curb has two cars [A,B], but is required to have [C,A] or [B,C] (A 7 ^ 
C, B 7 ^ C), then its cost is 3; otherwise, the cost is the number of incorrectly-positioned 


cars. 
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Table 1. The number of instances solved optimally. 


Donnain 

# insts 

Picat 

Picat-nt 

Picat-nh 

Synnba 

Barman 

14 

14 

0 

14 

6 

Cave 

20 

20 

0 

20 

3 

Childsnack 

20 

20 

20 

20 

3 

Citycar 

20 

20 

17 

18 

17 

Floortile 

20 

20 

0 

20 

20 

GED 

20 

20 

19 

13 

19 

Parking 

20 

11 

4 

0 

1 

Tetris 

17 

13 

13 

9 

10 

Transport 

20 

9 

0 

4 

8 


7 Experimental Results 


In addition to the four domains presented in this paper, we have encoded in Picat several 
other domains used in the deterministic sequential track of IPC’14. The domains and their 
Picat encodings are given in Appendix A. The Picat encodings are simple, compact, and 
comparable in size with the PDDL encodings used in IPC’14. Most of the encodings can 
be further improved by incorporating sophisticated domain knowledge and heuristics. In 
order to evaluate the effectiveness of the use of tabling and the use of heuristics, we have 
built two separate sets of encodings, namely, Picat-nt and Picat-nh, which use the same 
state representation as the original Picat encodings but have some component removed. 
Picat-nt performs Prolog-style non-tabled iterative-deepening search. Since Picat-nt does 
not table any state, it may explore the same state multiple times during search. The 
Picat-nh encodings do not use any heuristics. We have compared these Picat encodings 


with the IPC’14 PDDL encodings solved with Symba (Torralba et al. 2014), a domain- 


independent bidirectional A* planner which won the optimal sequential track of IPC’14. 
This comparison offers a glimpse of how well Picat compares with the best domain- 
independent planner. A comparison of Picat’s planner and several domain-dependent 
planners also shows the promise of tabled planning ( [Bartak et al. 2015 ). 

Table shows the number of instances (#insts) in the domains used in IPC’14 and 
the number of (optimally) solved instances by each planner. The results were obtained 
on a Cygwin notebook computer with 2.4GHz Intel i5 and 4GB RAM. Both Picat and 
Symba were compiled using g++ version 4.8.3. For Symba, a setting suggested by one of 
Symba’s developers was used. A time limit of 30 minutes was used for each instance as 
in IPC. For every instance that was solved by both Symba and Picat, the plan quality is 
the same. 

A comparison of Picat and Picat-nt shows the effectiveness of the use of tabling. For ev¬ 
ery domain, except for Childsnack and Tetris^ Picat solved more instances than Picat-nt. 
For Barman^ Cave, Floortile and Transport, Picat-nt could not solve any of the instances. 
The Picat encodings for five of the domains {Citycar, GED, Parking, Tetris, and Trans¬ 
port) use heuristics. The use of heuristics is helpful for these domains, especially for 
Parking, for which Picat-nh did not solve any of the instances. 

Picat solved more instances than Symba for every domain except for Floortile, for which 
both systems solved all of the instances. The running times of the instances are not given, 
but the total runs for Picat were finished within 24 hours, while the total runs for Symba 
took more than 72 hours. 
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8 Conclusion and Future Work 


This paper has presented Picat’s planner, its implementation, and example models for 
several domains from IPC’14. The example models illustrate several modeling techniques 
in Picat. One key task of modeling is finding an efficient state representation. While 
classical planning frameworks such as PDDL are based on a factored representation of 
states, Picat uses a structured representation. A structured state representation can leave 
out unnecessary information that is not needed for planning and can break symmetries by 
avoiding enumerating all possible permutations of objects. Another key task of modeling 
is utilizing domain knowledge to reduce search spaces. In the past, a lot of work has been 


done on the use of domain knowledge in planning (Bacchus and Kabanza 2000 Haslum 


and Scholz 2003 Kautz and Selman 1998), but recently, this part of modeling has been 
put aside, because of the advancement of domain-independent PDDL planners. This 
paper has shown that, even with simple domain knowledge, the declarative encodings of 
Picat significantly outperform Symba, a state-of-the-art domain-independent planner. 

This paper has demonstrated for the first time that tabled logic programming is com¬ 
petitive with the cutting-edge PDDL planners. The key to the success is tabling. Tabling 
avoids repeating the exploration of the same state and facilitates performing resource- 
bounded search. The Picat planner does not do prior grounding that is typical for most 
current state-space search planners, and hence Picat has no problem with exploded mem¬ 
ory consumption due to grounding. Nevertheless, memory consumption can be demand¬ 
ing during search since every encountered state is tabled. This is why careful modeling 
that removes symmetries and uses domain control knowledge to prune useless state tran¬ 
sitions is important. 

A good state representation should also exploit the underlying term-sharing technique 
that is used in the tabling system. In the examples that are presented in this paper, 
ordered lists are used to represent collections of objects. It takes linear time to perform 
the basic operations. One direction for future work is to design data structures for state 
representations which are compact, efficient, and good for sharing. 

A plethora of action languages have been designed for modeling and solving planning 


problems (e.g., A and its successors (Gelfond and Lifschitz 1998), Golog (Levesque et al. 
1997), and K ( Eiter et al. 2QQ4[ )). The focus of these languages has been on the modeling 
power rather than efficiency and scalability. These languages have been implemented 


by translation into SAT, ASP, CP, or PDDL (Baier et al. 2011 Dovier et al. 2011), 


but no implementation has been shown to be competitive with the cutting-edge PDDL 
planners. Picat can be used as an implementation language for these action languages. 
Like in PDDL, a state is represented as a set of flat facts in all of these action languages. 
Another direction for future work is to devise an efficient translation from these action 
languages into Picat that automatically exploits structural representation, symmetries, 
domain control knowledge, and heuristics. 
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Appendix A Benchmarks used in the paper 

In this section we summarize, for reader’s convenience, the descriptions of all the domains 
used as benchmarks. Descriptions are drawn from https: //helios . hud. ac. uk/scommv/ 
IPC-14/domains_sequential .html; Picat’s complete encodings for these benchmarks 
are available at http://picat-lang.org/ipcl4/, 


A,1 Barman 

There is a robot barman that manipulates drink dispensers, glasses, and a shaker. The 
goal is to find a plan of robot’s actions that serves a desired set of drinks. Robot hands 
can grasp at most one object at a time. Glasses need to be empty and clean to be filled. 
The benchmark was proposed by Sergio Jimenez Celorrio. 


“/o/o INITIAL state 
ontable(shaker1), 

... , 

clean(shaker1), 

... , 

empty(shaker1), 

dispenses(dispenserl,ingredientl), 
dispenses(dispenserS,ingredients), 
handempty(left), 

“/o/o Cocktail rules 

cocktail_partl (cocktail 1, ingredientl) , 


ontable(shot1), 
ontable(shots), 
clean(shotl), 
clean(shot8), 
empty(shot1), 
empty(shots), 

dispenses(dispenser2,ingredient2), 
dispenses(dispenser4,ingredient4), 
handempty(right), 

cocktail_part2(cocktaill, ingredients), 


cocktail_partl (cocktails, ingredient2) , 
“/o/o GOAL 

contains(shotl,cocktaill), 
contains(shots,cocktail2), 





cocktail_part2(cocktails,ingredientl), 

contains(shot2,cocktaill), 
contains(shot4,cocktails). 



Fig. A 1. Example of Barman 



In Figure |AT] we represent the initial configuration and the corresponding input spec¬ 
ifications. 
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Actions available are: 

• grasp (OBJ) that executes the grasping either of a specific shot or shaker (OBJ) 

• leave (OBJ) that allows us to leave the shot or shaker (OBJ) 

• fill_shot(SHOT,ING) that allows us to fill the shot SHOT with the ingredient ING 

• empty_shot (SHOT) (resp., empty_shaker(SHAKER)) that allows us to empty the 
shot SHOT (resp., the skaker SHAKER) 

• clean_shot (SHOT) (resp., clean_shaker (SHAKER)) that allows us to clean the shot 
SHOT (resp., the skaker SHAKER) 

• pour_shot_to_shaker(SHOT,SHAKER) (resp., pour_shaker_to_shot (SHAKER,SHOT)) 
that allows us to pour the content of the shot SHOT in the shaker SHAKER (resp., 
vice versa). 

• shake (SHAKER) that executes that shaking of the shaker to mix the ingredients. 

• reduce (remove a shot from the state once it contains a required cocktail 

All actions have cost 1 but reduce that has cost 0. 

A . 2 Cave Diving 

There is a set of divers, each of who can carry four tanks of air. These divers must 
be hired to go into an underwater cave and either take photos or prepare the way for 
other divers by dropping full tanks of air. The cave is too narrow for more than one 
diver to enter at a time. Divers have a single point of entry. Certain rooms of the cave 
branches are objectives that the divers must photograph. Swimming and photographing 
both consume air tanks. Divers must exit the cave and decompress at the end. They can 
therefore only make a single trip into the cave. Certain divers have no confidence in other 
divers and will refuse to work if someone they have no confidence in has already worked. 
Divers have hiring costs inversely proportional to how hard they are to work with. This 
domain was proposed by Nathan Robinson, Christian Muise, and Charles Gretton. 

The cave system is represented by an undirected acyclic graph. Divers can carry an 
amount of tanks according to their capacity. Rooms that need to be reached are among 
the leaves of the graph. In Figure [A^ we represent an instance of the problem. 

The actions available are: 

• hire_diver (Diver) that requires the availability of hiring cost and should satisfy 
the compatibility constraints among divers, 

• prepare_tank(T) that prepares the tank T for the current diver if his capacity 
allows it, 

• enter .water that requires the diver to be in the cave entrance, 

• photograph(Loc) that requires the diver to be in the target location Loc, 

• drop_tank(Loc) that allows the diver to leave a tank in the location Loc (the tank 
can be either full or empty), 

• swim (Loc 1 ,Loc2) that allows the diver to swim between two locations that are 
adjacent in the graph, 

• pickup .tank (Loc) that allows the diver to collect a tank stored in the location 
Loc, 

• decompress should be made at the end of diving in the cave entrance. 

Each action swim and photograph consumes (empties) one air tank. All actions but the 
first one have unitary cost. 
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yo7o Divers information 


available(dO) 


available(dl) 

available(d2) 

capacity(dO,four) 


capacity(dl,four) 

capacity(d2,four) 

=(hiring_cost(dO),60) 

precludes(dl,d2) 

yo7o Cave and tank information 

in_storage(tl) 

=(hiring_cost(dl),10) 

=(hiring_cost(d2),10) 

next_tank(tl, t2) 
cave_entrance (10) 



next_tank(t8,t9) 

connecteddO, 11) , 
“/oyoGOAL 

have_photo(14) 
decompressing(dO) 
decompressing(d2) 

0 

have_photo(15) 
decompressing(dl) 
de c ompr e s sing(d3) 

connected(15,11) 




Fig. A 2. Example of Cave Diving instance 


A . 3 Childsnack 

This domain is to plan how to make and serve sandwiches for a group of children in 
which some are allergic to gluten. There are two actions for making sandwiches from their 
ingredients. The first one makes a sandwich and the second one makes a sandwich taking 
into account that all ingredients are gluten-free. There are also actions to put a sandwich 
on a tray and to serve sandwiches. Problems in this domain define the ingredients to 
make sandwiches at the initial state. Goals consist of having selected kids served with a 
sandwich to which they are not allergic. This domain was proposed by Raquel Fuentetaja, 
Tomas de la Rosa Turbides. 

Available actions are the following: 

• make_sandwich_no_gluten(Sw,B,Co) and make_sandwich(Sw,B,Co) where SW is a 
sandwich, B is a (no-gluten) bread, and Co is a (no-gluten) content allows us to 
make the sandwiches. 

• put_on_tray(Sw,T) puts the sandwich Sw on the tray T 
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70% Positions 
at(tray1,kitchen) 
at_kitchen_bread(breadl) 
at_kitchen_bread (breads) 
at_kitchen_content (contentl) 
at_kitchen_content (contents) 
at_kitchen_content (contents) 
no _gluten_bread (breads) 
no_gluten_content (contentl) 
waiting(childl,table1) 
waiting(childS,tableS) 

7o7o Info on allergies 
allergic_gluten(child2) 

7o7o Not yet ready sandwhiches 
notexist(sandwl) 
notexist(sandwS) 
notexist(sandwS) 

7o7o Goal 
served(child2) 


at(tray2,kitchen) 
at _kit chen_br ead (br ead2) 

at_kitchen_content (content 2) 
at_kitchen_content (content4) 

no_gluten_content (content 4) 
waiting(child2,table2) 
waiting(child4,table4) 

allergic_gluten(child4) 

notexist(sandw2) 
notexist(sandw4) 
notexist(sandwS) 

served(childS) 




Fig. A3. Example of Childsnack instance 


• serve_sandwich_no_gluten(Sw,Ch,T,Loc) and serve_sandwich(Sw,Ch,T,Loc) serves 
the (no-gluten) sandwich Sw which is on tray T to the children Ch at the location 
Log 

• move_tray(TjLocl,Loc2), where T is a tray, Loci and Loc2 is a location (i.e., a 
table, the kitchen) 


Each action has cost 1. make .sandwich (no-gluten) consumes ingredients. 
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A. 4 City car 

This model aims to simulate the impact of road building/demolition on traffic flows. A 
city is represented as an acyclic graph, in which each node is a junction and edges are 
“potential” roads. Some cars start from different positions and have to reach their final 
destination as soon as possible. The agent has a finite number of roads available, which 
can be built for connecting two junctions and allowing a car to move between them. 
Roads can also be removed, and placed somewhere else, if needed. In order to place 
roads or to move cars, the destination junction must be clear, i.e., no cars should be in 
there. The domain was proposed by Mauro Vallati. 


VL Initial State 

same_line ( junction0_0, junctionO_l) 
same_line ( junctionl.O, junctionl_l) 
same_line ( junction0_0, junctionl_0) 
same_line ( junctionO_l, junctionl_l) 
diagonal ( junction0_0, junctionl_l) 
diagonal ( junctionO_l, junctionl_0) 
clear(junction0_0) 
clear(junctionl.O) 
at _garage(garageO,junctionO_l) 
starting(carO,garageO) 

VL GOAL 

arrived(carO,junctionl_l) 



same_line ( junctionO_l, junction0_0) 
same.line ( junctionl.l, junctionl.O) 
s ame _1 ine ( j unc t i on 1 _0, j unc t i onO _0) 
same_line ( junctionl_l, junctionO_l) 
diagonal ( junctionl.l, junction0_0) 
diagonal ( junctionl_0, junctionO_l) 
clear(junctionO_l) 
clear(junctionl_l) 

starting(carl,garageO) 

arrived(carl,junctionl_0) 



garage 0 


Fig. A 4. Example of Citycars instance 


Allowed actions are the following: 

• car_arrived(Dest), which has cost 0. It allows to remove a car from the network 
and to remove the occurrence of the destination Best (a junction) from the list of 
all final destinations. 

• car .start (Log) : A car is put in the road from the garage of location Loc: it has 
cost 1. 

• move_car_in_road(FromLoc) allows us to move a car in a road from the junction 
FromLoc (cost 1—the road is a straight line or a diagonal road starting in FromLoc). 

• move_car_out_road(ToLoc) allows us to move a out of a road as soon as the junc¬ 
tion ToLoc is reached by the car (cost 1—the road is a straight line or a diagonal 
road ending in ToLoc). 
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• These actions allow us to build diagonal, straight roads or of deleting one road: 

— build_diagonal_oneway (FromLoc jToLoc) (cost 30), 

— build_straight.oneway(FromLoc jToLoc) (cost 20), 

— destroy_road(FromLoc,ToLoc) (cost 10). 

Let us observe that search symmetries are eliminated by considering the cars equivalent 
during the search. It is trivial to label them a-posteriori given a correct plan. 


A,5 GED 

The GED problem is to find a min-cost sequence of operations that transforms one 
genome (signed permutation of genes) into another. The purpose of this is to use this 
cost as a measure of the distance between the two genomes, which is used to construct 
hypotheses about the evolutionary relationship between the organisms. The domains was 
proposed by Patrik Haslum. 

This problem can be stated at several abstraction levels. A general version could include 
gene insertions and deletions. Let us focus on the abstraction level and on the three rules 
required by the competition benchmarks. 

A gene is identified by a symbolic name. The connection between genes is stated by 
a binary predicate cw that encodes a linear graph. Each gene can occur in a regular 
direction (normal) or in reverse direction (inverted). 

The three rules allowed are cut (of a substring) from the main genome, and then a 
splice of the cut substring directed or reversed in a selected point of the main genome. 
The reverse of a single gene is also allowed. Just to fix the ideas, let us consider the 
example in figure [A5l Reversed genes are overlined. 


r/o INITIAL STATE 

normal(a), 
normal(b), 
normal(c), 
normal(d), 
cw(a,b), 
cw(b,c), 
cw(c,d) 


a • b • c • d 

k (cut 2-4, temp situation) 
a b • c d 

k (cut 2-4, final situation) 
a • d b • c 

k (reverse of the 2nd string) 
a • d c • b 

k (and splice in the 1st) 
a • c • b • d 


7o7o GOAL 

normal(a), 
inverted(b), 
inverted(c), 
normal(d), 
cw(a,c), 
cw(c,b), 
cw(b,d) 


Eig. A 5. An instance of the GED problem and a possible solution 


Each complex action (cut and splice) is split in some sub-actions as done by Patrik 
Haslum in his PDDL encoding (http://picat-lang.org/ipcl4/ged.pddl). 


A,6 Floortile, Parking, and Tetris 

Eor the three domains discussed extensively in the core of paper we only show here an 
instance both in concrete form and as a picture (see Eigures A6-A8). The Transport 
domain is discussed in detail in the next section. 
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7o7o Floor description 

clear(01) 

up(ll,01) 

down(01,ll) 

right(02,01) 

left(01,02) 

7o7o Robots positions and states 
robot_at(robot1,11) 
robot_at(robot2,52) 
available_color(white) 

7o7o GOAL 

painteddl, white) 
painted(13,white) 


clear(64), 
up(64,54), 
down(54,64) 
... right(64,63) 
left(63,64) 


robot_has(robot1,white) 
robot_has(robot2,black) 
available_color(black) 


painted(12,black) 
painted(14,black) 


painted(61,black) 
painted(63,black) 


12 3 4 



painted(62,white) 
painted(64,white) 



Fig. A 6. Example of Floortile instance. A solution with plancost 104 exists (benchmark 
instance p01642). 








Planning as Tabled Logic Programming 


23 


r/o INITIAL STATE 


at_curb(car3), 
behind_car(car2,car3), 
at_curb(car4), 
behind_car(carlo,car4) , 
at_curb(carO), 
behind_car(car5,car0), 
at_curb(carl) , 
behind_car(car9,carl), 
at_curb(car7), 
behind_car(cars,car?), 
at_curb(carll), 
behind_car(car6,carll), 
curb.clear(curbs) 

r/o GOAL 


at_curb_nuin(car3,curbO), 
car_clear(car2), 
at_curb_nuin(car4,curbl), 
car.clear(carlo), 
at_curb_nuin(carO,curb2), 
car.clear(car5), 
at .curb .nuin( carl, curb3), 
car.clear(car9), 
at_curb_nuin(car7,curb4), 
car.clear(cars), 
at .curb _nuin(c aril, curbs), 
car.clear(car6), 


at.curb.num(carO,curbO), 
at_curb_num(carl,curbl), 
at_curb_nuin(car2,curb2), 
at.curb.num(car3,curbs), 
at_curb_num(car4,curb4), 
at_curb_nuni(car5,curbs) , 



behind.car(car7,carO) , 



behind.car(cars,carl) , 
behind.car(car9,car2) , 
behind.car (carlo, car3), 
behind.car(carll,car4), 
at_curb_nuin(car6, curbs) 


I 


Fig. A 7. An instance of parking (left: initial state, right: goal). A solution with 18 moves 
exists (benchmark instance p_12_7_0l). 
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“/o'/o Board description 
connected(fO_Of), 
connected(fl_lf,fl_0f), 


connected (f 0_2f ,f0_3f) 
connected(fl_2f, 


connected(f6_0f ,f7_0f), 
clear (f0_3f) , 

70% Pieces 

at_right_l(rightlO,f 0_0f,f l_0f,f l_lf), 
at_two(straight0,f0_2f ,fl_2f) , 

7o7o Goal 
clear(f0_0f), 
clear(fl_0f) 
clear(f2_0f) 
clear(f3_0f) 


connected(f6_3f,f7_3f) 
clear(f7_3f), 

at_right_l (rightll, f 2_lf, f 3_lf, f 3_2f), 
at .square(squareO,f0_lf ) 

clear(f0_3f) 
clear(fl_3f) 
clear(f2_3f) 
clear(f3_3f) 




Fig. A8. Example of Tetris instance: initial state (left), goal (center). A plan of length 
36 exists (instance 01_8 of the benchmarks) leading to the final situation to the right. 
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Appendix B The Transport Domain 
BA PDDL Encoding of the Transport Domain 

(define (domain transport) 

(:requirements :typing :action-costs) 

(:types 

location target locatable - object 
vehicle package - locatable 
capacity-number - object 

) 

(:predicates 

(road ?11 ?12 - location) 

(at ?x - locatable ?v - location) 

(in ?x - package ?v - vehicle) 

(capacity ?v - vehicle ?sl - capacity-number) 

(capacity-predecessor ?sl ?s2 - capacity-number) 

) 

(:functions 

(road-length ?11 ?12 - location) - number 
(total-cost) - number 

) 

(:action drive 

:parameters (?v - vehicle ?11 ?12 - location) 

:precondition (and 
(at ?v ?11) 

(road ?11 ?12) 

) 

:effect (and 

(not (at ?v ?11)) 

(at ?v ?12) 

(increase (total-cost) (road-length ?11 ?12)) 

) 

) 

(:action pick-up 

:parameters (?v - vehicle ?1 - location ?p - package ?sl ?s2 - capacity-number) 

:precondition (and 
(at ?v ?1) 

(at ?p ?1) 

(capacity-predecessor ?sl ?s2) 

(capacity ?v ?s2) 

) 

:effect (and 

(not (at ?p ?1)) 

(in ?p ?v) 

(capacity ?v ?sl) 

(not (capacity ?v ?s2)) 

(increase (total-cost) 1) 

) 

) 

(:action drop 

:parameters (?v - vehicle ?1 - location ?p - package ?sl ?s2 - capacity-number) 

:precondition (and 
(at ?v ?1) 

(in ?p ?v) 

(capacity-predecessor ?sl ?s2) 

(capacity ?v ?sl) 

) 

:effect (and 

(not (in ?p ?v)) 

(at ?p ?1) 

(capacity ?v ?s2) 

(not (capacity ?v ?sl)) 

(increase (total-cost) 1) 

) 

) 


) 
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B.2 Picat Encoding of the Transport Domain 

final({Trucks,[]}) => % no waiting packages and no loaded packages 

foreachC[_Loc,DestsI_] in Trucks) 

Bests == [] 

end. 

% unload a package 

action({Trucks,Packages},NextState,Action,ActionCost), 
select([Loc,Bests,Cap],Trucks,TrucksR), 

select(Loc,Bests,BestsR) % unload it deterministically 

=> 

Action = $unload(Loc), 

ActionCost = 1, 

NewTrucks = insert_ordered(TrucksR,[Loc,BestsR,Cap]), 

NextState = {NewTrucks,Packages}. 
action({Trucks,Packages},NextState,Action,ActionCost) ?=> 

Action = $unload(Loc), 

ActionCost = 1, 

select([Loc,Bests,Cap],Trucks,TrucksR), 
select(Best,Bests,BestsR), 

NewTrucks = insert_ordered(TrucksR,[Loc,BestsR,Cap]), 

NewPackages = insert_ordered(Packages,(Loc,Best)), 

NextState = {NewTrucks,NewPackages}. 

7o load a package onto a truck if the truck and the package are at the same location 
action({Trucks,Packages},NextState,Action,ActionCost) ?=> 

Action = $load(Loc), 

ActionCost = 1, 

select([Loc,Bests,Cap],Trucks,TrucksR), 
length(Bests) < Cap, 

select((Loc,Best),Packages,PackagesR), % the package is at the same location as the truck 

NewTrucks = insert_ordered(TrucksR,[Loc,insert_ordered(Bests,Best),Cap]), 

NextState = {NewTrucks,PackagesR}. 

% drive a truck from Loc to NextLoc 

action({Trucks,Packages},NextState,Action,ActionCost) => 

Action = $move(Loc,NextLoc), 
select([Loc|Tail],Trucks,TrucksR), 
road(Loc,NextLoc,ActionCost), 

NewTrucks = insert_ordered(TrucksR,[NextLoc|Tail]), 

NextState = {NewTrucks,Packages}, 

estimate_cost(NextState) =< current_resource()-ActionCost. 
table 

estimate_cost({Trucks,Packages}) = Cost => 

LoadedPackages = [(Loc,Best) : [Loc,Bests,_] in Trucks, Best in Bests], 

NumLoadedPackages = length(LoadedPackages), 

TruckLocs = [Loc : [Loc|_] in Trucks], 

travel_cost(TruckLocs,LoadedPackages,Packages,0,TCost), 

Cost = TCost+NumLoadedPackages+length(Packages)*2. % includes load and unload costs 

% the maximum of the minimum cost of transporting each single package 

travel_cost(.Trucks,[],[],CostO,Cost) => Cost=CostO. 

travel.cost(Trucks,[(PLoc,PBest)[Packages],Packages2,CostO,Cost) => 

Costl = min([Bl+B2 : TLoc in Trucks, 

shortest.dist(TLoc,PLoc,B1), 
shortest.dist(PLoc,PBest,B2)]), 
travel.cost(Trucks,Packages,Packages2,max(CostO,Costl),Cost). 
travel.cost(Trucks,[],Packages2,CostO,Cost) => 
travel.cost(Trucks,Packages2,[],CostO,Cost). 
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B.3 An Instance of the Transport Domain 



Fig. B 1. An Instance of the Transport Domain (pOl). 


B.3.1 Solving the instance with Picat 


main => 

Facts = 

$[road(c3,cl,40),road(cl,c3,40),road(c3,c2,18), 
road(c2,c3,18),road(c4,c1,36),road(cl,c4,36), 
road(c4,c3,37),road(c3,c4,37),road(c5,c2,24), 
road(c2,c5,24),road(c5,c3,26),road(c3,c5,26)], 
cl_facts(Facts,[$road(+,-,-)]), 

Trucks = [[c2, [] ,3] , [cl, [] ,2]] , 

Packages = [(cl,c2),(cl,c2),(c3,cl),(c2,c5)], 
best_plan({sort(Trucks),sort(Packages)},Plan,PlanCost), 
foreach ({I,Action} in zip(l..len(Plan),Plan)) 
printf ("7o3d. 7ow\n" , I,Action) 

end, 

println(plan_cost=PlanCost). 


B.3.2 An Optimal Plan for the Instance 


1. load(cl) 

2. load(cl) 

3. load(c2) 

4. move(cl,c3) 

5. move(c2,c5) 

6. unload(c5) 

7. move(c3,c2) 

8. unload(c2) 

9. unload(c2) 

10. move(c2,c3) 

11. load(c3) 

12. move(c3,cl) 

13. unload(cl) 


plan_cost = 148 










